In February of 2011, we decided that crowd needed to be upgraded as a part of a larger upgrade scheme for our software development infrastructure. Here is a diagram of the overall infrastructure that we are moving towards.

Upgrade process

Fortunately, Atlassian is very good about documenting their upgrades and installations and the upgrade of Crowd basically was an export from the old and an import to the new. The process started with Crowd being at version 1.6 and we upgraded to 2.1. Since we are using MSSQL, Atlassian recommends the export and import method of upgrading. So here are the steps I took:

1. I put in request for a virtual machine in the DMZ and had it named crowd.mbari.org. The old version was hosted on oceana, so there was no name clash. Pat created the VM (RHEL 5) and then installed Java version 1.6.0_23.
2. I did not really need to backup the existing crowd install, because this is a new install that I will migrate the database over to. That said, I did backup the /opt/crowd/crowd-openidserver-webapp/WEB-INF/classes/crowd.properties and created a tar file of the /data/crowd directory and put them in /root/backup-02-15-2011 so that I at least had them.
3. I downloaded latest jtds driver (1.2.5) and the version 2.1.1 or atlassians crowd product.
4. I went to the administration console of the current crowd installation and did a backup export to XML:
   1. Clicked on Administration 'tab'
   2. Clicked on 'Backup'
   3. I left the check box to clear the domain so it can be restored on the new server and put the file as /tmp/crowd/02-15-2011.xml
   4. I then moved the file to /root/backup-02-15-2011/crowd
5. I expanded the atlassian download into the /opt directory then created a link to it using 'ln -sf /opt/atlassian-crowd-2.1.1 /opt/crowd' so it would make upgrades easier (startup scripts).
6. I then created the /data/crowd directory to house the data for the crowd application.
7. I edited the /opt/crowd/crowd-webapp/WEB-INF/classes/crowd-init.properties file and pointed the crowd.home property to /data/crowd
8. I then moved the jtds driver jar file to the /opt/crowd/crowd-webapp/WEB-INF/lib directory
9. I copied the 02-15-2011.xml file to from the old crowd installation on oceana to the /tmp directory on crowd.mbari.org.
10. I then ran the startup script start_crowd.sh from the /opt/crowd directory
11. I then browsed to http://localhost:8095/crowd to get to the setup wizard. (I did this from the local machine as I could not get to 8095 from anywhere else).
12. It prompted me for the license, so I took the server ID from this page, logged in to my altassian account, viewed the renewed license for crowd and stuck the server ID in from the crowd license page. This generated a new license key, which I put back into the license key field on the crowd installation page.
13. It then asked me if this was a new installation or if I wanted to restore from XML backup. I chose the backup method and then clicked next.
14. It then asked me what type of database I had and I chose JDBC connection. I then filled in the appropriate parameters for the connection.
    1. Database: Microsoft SQL Server
    2. Driver Class Name: net.sourceforget.jtds.jdbc.Driver
    3. JDBC URL: jdbc:jtds:sqlserver://equinox.shore.mbari.org:51001/Crowd;domain=SHORE
    4. Username: DB_Collaboration
    5. Password: wouldn't you like to know
    6. Hibernate Dialect: org.hibernate.dialect.SQLServerDialect
    7. Overwrite Existing Data: Checked
15. I then chose the /tmp/02-15-2011.xml file as the import from backup file.
16. It then told me success and sent me to the crowd console for login

    Firewall holes In order to get this to work, I had to get I.S. to get some firewall holes punched from crowd.mbari.org to equinox.shore.mbari.org port 51001 and ldap.shore.mbari.org port 389.

17. Now in order to harden it up a bit, I followed the instructions here but used the user and group DB_Collaboration instead of the crowd user and group.
18. The final step was to setup the SSL certificate and enable it in Crowd.
19. Cathy was nice enough to get the certificate and keystore all setup and then I had to enable it for Crowd. Cathy did step 2 on the following page and I had to do steps 1, 3 and 4.
    1. I shut down the crowd service and then did step 1 (and I used the extra SSLEnabled attribute).
    2. I did step 3 and 4 and brought it back up.
    3. Note I also commented out the <Connector> tag on port 8085 so that the straight http port was closed.
20. I.S. then opened up port 8443 to the world

OpenID

1. I enabled CrowdID on this server as well.
2. Mike Godin found some redirects were not happening correctly:

   I'm wondering if maybe it's a hostname issue.  The redirections I see are:
   
   #1 from login page, GET https://crowd.mbari.org:8443/openidserver/server.openid?openid.assoc_handle=<lots of stuff deleted>
   
   #2 redirected GET to https://crowd.mbari.org:8443/openidserver/secure/interaction/allowauthentication!default.action
   
   #3 redirected GET to https://localhost:8443/openidserver  !!!!
      It should have redirected to https://crowd.mbari.org:8443/openidserver
   
   Weird thing is that the redirection in step 2 is correct.  But for some reason crowd.mbari.org forgets it's host name in step 3.  I guess this is why things work when a user is already logged into crowd, because only steps #1 and #2 need to occur.
   

   On the web I found this:

   I found out the solution !
   
   In crowd-openidserver-webapp\WEB-INF\classes\crowd.properties the following values are set:
   
   application.login.url http://localhost:8095/openidserver
   crowd.server.url http://localhost:8095/crowd/services/ 
   
   After changing "localhost" to the the correct hostname/ip-address, the redirect is working as expected.
   

   I also made this change and I am waiting to hear from Mike G. I also changed the 'localhost' to 'crowd.mbari.org' in the /data/crowd.properties file to make sure redirects happen OK there too.